The advent of the personal computer (PC) has enabled a variety of low cost processing systems such as image processing & machine vision system designs based on standardized hardware which take advantage of the technological innovation of the PC market.
Four typical configurations of such PC based image processing and/or machine vision systems that are widely used today are highlighted below. In the simplest configuration of such as system, a frame grabber or camera interface board or system resides on the PC's peripheral bus and is used to acquire images from one or more cameras into the PC's memory where the images can be accessed and processed by the PC CPU. This will be referred to as the frame grabber or host processing configuration since the host CPU is solely responsible for all image processing operations.
Another class of such systems uses a plug-in processor accelerator board to assist the PC CPU in performing some of the computationally expensive and extensive image processing operations. This will be referred to as the vision accelerator or accelerated host processing configuration.
Yet another possible configuration involves a complete image processing or machine vision subsystem in the form of an expansion board plugged in the PC's peripheral bus. This board features and on-board CPU, often also coupled with dedicated image processing acceleration hardware. In this configuration, the embedded or target CPU completely off-loads all vision processing operations from the host PC CPU which can now be dedicated to user interface, control, or other tasks running on it concurrently with the image/vision processing tasks running on the vision processor. This multiprocessing configuration will be referred to as the embedded vision processing engine or target processing configuration.
A final configuration uses the PC only as the programming and/or user interface environment for a standalone vision processing engine connected to it through a high speed serial or network connection. This configuration will be referred to as the standalone vision processing engine or standalone target processing configuration.
Most recently, the PCI bus.sup.1 has enabled high bandwidth data transfers between a plug-in device such as an image acquisition or image processing board and the host PC, further enhancing the performance of all the above mentioned embedded system configurations.
The wide availability of PCI compatible components for the PC market makes it also attractive as a local bus to be used inside a processing subsystem such as the above mentioned image or vision processing subsystem configurations.
Use of the PCI bus as a local bus is not without its drawbacks however. For example, the PCI bus was designed primarily for the PC market and as such, the topology and data flow is directed from a host CPU through a host bus bridge to a tree of peripheral buses connected through PCI to PCI bridges (herein referred to as peripheral bridges). The host CPU expects to be the only CPU in the system and also expects that its main memory is fixed in the system memory map. Any plug-in card, board or device with an embedded CPU has to allow its local memory to be mapped to avoid conflict with the host PC memory. Memory assignments may come from one or two sources: PCI BIOS or the host operating system (OS). Care must be taken when necessary to avoid system lockups by either hiding devices behind the peripheral bus bridges (where they are inaccessible by the host PC system), or by temporarily disconnecting them from the PCI bus until they are ready to accept bus transactions.
A further drawback to using the PCI bus as a local bus inside PCI based systems is caused by a video graphics adapter (VGA), herein referred to as the display controller, and the discovery process used by the PCI BIOS and host Operating System (OS) to determine the system display controller. There are many different PCI BIOS manufacturers using different discovery algorithms some of which become confused by more than one display controller on the PCI bus. Also, PCI adapter card manufacturers who write drivers for their products sometimes introduce problems, e.g. when an expansion card has a peripheral bridge chip.